Establishing a Communication Event Using Secure Signalling

ABSTRACT

A communication event is established between an initiating device and a responding device under the control of a remote communications controller. In a pre-communication event establishment phase, a secure connection is established between the initiating device and the communications controller, and session key negotiation messages are exchanged between the initiating device and the communications controller via the secure connection to obtain session key data in an electronic storage location accessible to the initiating device. The secure connection terminates once the session key data has been obtained. In a subsequent communication event establishment phase—after the session key data has been obtained and the secure connection has terminated in the pre-establishment phase—a communication event request is transmitted from the initiating device to the communications controller comprising a payload encrypted with the session key data.

BACKGROUND

A communication event may be established between an initiating device(that is, a calling device) and at least one responding device (that isa callee device). The communication event may for example be a call(audio or video call), a screen or whiteboard sharing session, otherreal-time communication event etc. The communication event may bebetween the initiating device and multiple responding devices, forexample it may be a group call.

The communication event may be established by performing an initialsignalling process, in which messages are exchanged via a network, so asto provide a means by which media data (audio and/or video data) can beexchanged between the devices in the established communication event.The signalling phase may be performed according to various protocols,such as SIP (Session Initiating Protocol) or bespoke signallingprotocols. The media data exchange rendered possible by the signallingphase can be implemented using any suitable technology, for exampleusing Voice or Video over IP (VoIP), and may or may not be via the samenetwork as the signalling.

The communication event may be established under the control of acommunications controller, such as a call controller. That is, thecommunications controller may control at least the signalling process.For example, all messages of the signalling process sent to the callerand callee devices may be sent from the communication controller, andbetween the devices themselves. For example, the calling device mayinitiate the signalling process by sending an initial request to thecommunications controller, but the communications controller may havethe freedom to accept or reject the initial request. If the initialrequest is accepted, the communications controller itself may send outcall invite(s) to the call device(s), and the responding device(s) inturn may respond to the communications controller (not the initiatingdevice directly).

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

According to various aspects of the present subject matter, acommunication event is established between an initiating device and aresponding device under the control of a remote communicationscontroller.

In a pre-communication event establishment phase:

-   -   a secure connection is established between the initiating device        and the communications controller,    -   session key negotiation messages are exchanged between the        initiating device and the communications controller via the        secure connection to obtain session key data in an electronic        storage location accessible to the initiating device, and    -   the secure connection terminates once the session key data has        been obtained.

The session key data is for use by the initiating device in generatingencrypted message payloads that are decryptable by the communicationscontroller.

In a subsequent communication event establishment phase, a communicationevent request payload, for transmission to the communicationscontroller, is generated and encrypted by the initiating device usingthe session key data stored in the accessible electronic storagelocation. In response to a communication event establishment instructionreceived at the initiating device after the session key data has beenobtained and the secure connection has terminated in thepre-establishment phase, a communication event request is transmittedfrom the initiating device to the communications controller. Thecommunication event request comprises the encrypted request payload. Thecommunications controller is able to decrypt the encrypted requestpayload, allowing the communication event between the devices to beestablished under the control of the communications controller based onthe decrypted payload.

BRIEF DESCRIPTION OF FIGURES

For a better understanding of the present subject matter, and to showhow the same may be carried into effect, reference is made by way ofexample only to the following figures, in which:

FIG. 1 shows a known type of communication system;

FIG. 1A shows how a TCP connection may be secured using TLS;

FIG. 1B shows how UDP communications may be secured using DTLS;

FIG. 2 shows a block diagram of a communication system in whichembodiments of the present subject matter may be implemented;

FIG. 2A shows an exemplary call controller, in the form of a serverpool;

FIG. 3 shows a block diagram of a user device;

FIG. 4 shows how functionality may be implemented by an initiatingdevice at different architectural layers of a packet based network;

FIG. 5A shows a signalling diagram for a pre-call establishment phase;

FIG. 5B shows a signalling diagram for a subsequent call establishmentphase;

FIG. 5C shows additional signalling performed for the first request sentin the call establishment phase;

FIG. 6 shows a flowchart for a protocol fall back process;

FIG. 7 shows an exemplary data structure for application layer packets;and

FIGS. 8B and 8A demonstrate the operation of a compression function,with and without a compression dictionary respectively.

DETAILED DESCRIPTION OF EMBODIMENTS

Among other things, different aspects of the present disclosure arerespectively directed to:

-   -   1) a novel encryption method for use in providing secure        communications signalling (e.g. call signalling)—section 1,        below;    -   2a) a novel protocol fallback method, for use in communications        signalling—section 2 a, below; and    -   2b) a novel data compression method, for use in        communications-signalling—section 2 b, below.

As explained below, any of the above method can be combined with one orboth of the other methods. In the describe embodiments techniques allthree are combined to provide secure communications signalling overUDP—leading to reduced call setup times in most cases without comprisingsecurity. Thorough 1) and 2 a), it becomes possible, among other things,to encapsulate an encrypted, compressed message in a single transportlayer packet, an in particular a datagram of an unreliable transportlayer protocol such as UDP—which obviates the need for any applicationlayer reassembly mechanism and makes UDP viable in most cases for callsignalling—whilst 2 b) ensures that call signalling can fall back to TCPshould UDP be unavailable in a particular circumstance. This combinationprovides call signalling that is fast, secure and reliablenotwithstanding the preferred use of the unreliable transport protocol,e.g. UDP.

1) Secure Call Signalling

A communication event is established between an initiating device and aresponding device under the control of a remote communicationscontroller. The communication event establishment procedure is securedusing pre-exchanges session key data.

In a pre-communication event establishment phase:

-   -   a secure connection is established between the initiating device        and the communications controller,    -   session key negotiation messages are exchanged between the        initiating device and the communications controller via the        secure connection to obtain session key data in an electronic        storage location accessible to the initiating device, and    -   the secure connection terminates once the session key data has        been obtained.

The session key data is for use by the initiating device in generatingencrypted message payloads that are decryptable by the communicationscontroller.

In a subsequent communication event establishment phase, a communicationevent request payload, for transmission to the communicationscontroller, is generated and encrypted by the initiating device usingthe session key data stored in the accessible memory location. Inresponse to a communication event establishment instruction received atthe initiating device after the session key data has been obtained andthe secure connection has terminated in the pre-establishment phase, acommunication event request is transmitted from the initiating device tothe communications controller. The communication event request comprisesthe encrypted request payload. The communications controller is able todecrypt the encrypted request payload, allowing the communication eventbetween the devices to be established under the control of thecommunications controller based on the decrypted payload.

Among other things, the present subject matter provides:

-   -   (i) secure signalling between the initiating device and the        responding device during the initial establishment of the        communication event;    -   (ii) without increasing the call setup time; and    -   (iii) using minimal processing resources and network bandwidth.

In accordance with the present subject matter, the signalling itself isnot conducted via the secure connection, i.e. the communication eventrequest is not transmitted via the secure connection. The secureconnection is terminated before the communication event instruction isreceived, and the security of the signalling, i.e. (i), is provided, inthe communication event establishment phase, by the payload encryptionbased on the obtained session key data. The session key data is obtainedsecurely as the secure connection is used for its negotiation. This doesnot increase the call setup time, i.e. (ii), because the session keydata is pre-negotiated before the communication event is instructed,e.g. by a user of the initiating device; nor does it require excessiveprocessing resources or bandwidth, i.e. (iii), as the secure connectionis terminated once the session key data has been obtained, meaning thatprocessing and bandwidth are not required to keep the secure alive afterthe session key data has been obtained.

The term “call set up time” refers to a time interval from a time thecommunication event establishment instruction being received (which mayfor example be instigated manually by a user of the initiating device,for example by the user selecting an option to call the respondingdevice or a user thereof at the initiating device) to a time thecommunication event establishment request is transmitted. Note that theterm “call set up time” is used, for conciseness, in relation to bothcalls and other types of communication event, such as screen sharingsessions, shared whiteboard sessions, other real-time mediacommunication events etc.

In the context of a connection between an initiating device and acommunications controller, the term “connection” means a logicalconnection between the initiating device and the communicationscontroller that is:

-   -   established by performing at least one channel establishment        handshake procedure, in which at least one handshake message is        exchanged between the initiating device and the communications        controller; and/or    -   which is maintained by implementing a state machine for the        connection in memory of the initiating device and/or the        communications controller.

The connection is terminated when the state machine transitions to adisconnected state, for example when the connection

-   -   is torn down: i.e. by performing at least at least one        termination procure, in which at least one termination message        is exchanged between the initiating device and the        communications controller; and/or    -   expires i.e. upon expiry of an inactivity timer at the        initiating device and/or the communications controller (in which        case the connection may terminate without any termination        handshake procedure).

For example, the connection may be a TLS (Transmission Layer Security)or SSL (Secure Sockets Layer) connection established via a networkhaving a plurality of network layers, including an application layer anda transport layer above the transport layer. As is known, SSL and TLSrefer to earlier versions of the same protocol—“TLS” is used throughoutthis disclosure as shorthand for either TLS or SSL, and any disclosurepertaining to TLS herein applies equally to SSL.

A TLS connection is a TCP (Transmission Control Protocol) connection atthe transport layer that is secured using TLS. In this case, the statemachine may track both TCP and TLS state changes, in accordance with theTCP and TLS protocols respectively. For example, separate TCP and TLShandshake procedures are performed in this case, causing transitions ofthe TCP and TLS state machines respectively.

As another example, the connection may be a DTLS (Datagram TLS)connection established via the network. DTLS operates over UDP. AlthoughUDP is a connectionless transport protocol (i.e. transport layerprotocol), which has no state or handshake messages, the DTLS protocolitself defines both a handshake procedure and a state machine. In thiscase, the state machine at the initiating device and/or thecommunications controller tracks DTLS transitions, e.g. as the DTLShandshake procedure progresses, even though it does not track UDPdirectly.

As another example, the connection may be a higher level connection suchas an HTTPS (i.e. secure HTTP) connection. Note herein HTTP/TCP meansHTTP over TOP; HTTPS means HTTP over a TLS connection, that isHTTPS=HTTP/TLS.

No existing call set up procedure provides all three of the abovementioned effects i.e. all three of (i), (ii) and (iii).

The electronic storage location in which the session key data is storedcan be a location in any suitable type of electronic storage, forexample volatile and/or in-memory storage, long term storage (e.g. harddisk) available to the initiating device. Long term storage may be usedto make sure that the negotiated key survives reboots. For example,mobile phones may lose their power and then upon charge may berestarted, and because the communication client is not activated uponphone start up, there would be no chance to re-negotiate a new securitytoken. As such, it may be desirable to implementations may wish to keeppreviously-session key data safe to enable users to initiate acommunication event very fast, even in the event of a re-boot.

Note that references to “memory” hereinbelow can refer to any suchelectronic storage, including volatile memory (including processormemory) and non-volatile memory (such as flash or magnetic memory,including hard disks).

FIG. 1 shows an example of an existing type of communication system,which comprises a network 106 and connected to the network 106: a clientdevice 104, operated by a user 102, and a server 110, such as an SIPserver, 110. The network 102 is an internetwork (internet); that is, aplurality of interconnected, individual networks. The internet 102 has aplurality of network layers: a link layer 112, a network layer 114 abovethe link layer 112, a transport layer 116 above the network layer 114and an application layer 118 above the transport layer 116. The internet102 includes a plurality of routers 108, which route data at the networklayer 114 between individual networks of the internet 102. The networklayers 112-118 are not shown explicitly in FIG. 1, though they are shownin later figures. The internet 102 may for example the Internet (capitalI) or another internet operating in accordance with the TCP/IP ProtocolSuite, or more generally any network having a layered architecture, e.g.in accordance with the OSI model. Note that in the context of the OSImodel, references to “the application layer” herein denote all of OSI L5though L7, references to “the transport layer” denote OSI L4, referencesto “the network layer” OSI L3, and “the link layer” OSI L2-L1.

As illustrated in FIG. 1A, some existing call signalling techniques usesTLS (Transport Layer Security) for the signalling phase itself. A secureTLS connection 117 is established between an initiating device and aserver, and all call signalling messages are sent via the secureconnection 117. That is, the signalling messages between the initiatingdevice and the server are transmitted via a secure TLS connection, inaccordance with an application layer signalling protocol such as SIP. Asis well known in the art, TCP is a reliable, connection orientedtransport protocol (i.e. at the transport layer 116), whereas TLSoperates between the transport layer 116 and the application layer118—as illustrated in FIG. 1A.

Setting up the TLS connection 117 requires two exchanges of handshakemessages: 1) a first TCP handshake between the client device 102 and theserver 110 to establish a TCP connection between the imitating deviceand the server, and 2) a second TLS handshake to negotiate a TLS key forsecuring the TCP connection—the “TLS connection” 117 being the TCPconnection when secured in this manner.

Some such call signalling techniques set-up the TLS connection 117 atthe start of the signalling phase itself. For example, the secureconnection 117 is established in response to a user 102 of the clientdevice 102 selecting a call option at the client device 102. As aconsequence, the call setup time is dominated by TLS handshakes whichrequire multiple network roundtrips. That is, such techniques increasecall set up times significantly.

Other such existing signalling techniques utilize a pre-established,background TLS connection 117 to the server 110—that is, a persistentsecure connection 117 that is pre-established and maintained constantly,even when it is not needed. Whilst this can prevent call set up timesfrom being increased, keeping the background connection fresh requiresconstant resources—both network bandwidth and processing resources atboth the client device 102 and the server 110. That is, to maintain thebackground TLS connection 117, the client device 102 needs to consumeboth processing resources and network bandwidth continuously, as refreshmessages need to be sent repeatedly to the server 110 to keep theconnection 117 alive. This can for example result in higher batterydrain (for mobile devices in particular), and wasted bandwidth and,moreover, creates significant additional load on the server receivingthe refresh messages.

Another call signalling method uses unencrypted UDP for signalling. Thatis, call signalling messages are sent using UDP—an unreliable,connectionless transport protocol—but in an unencrypted form. Thisallows a fast call setup and does not require background connections tobe kept alive, however the signalling is not secure.

As is known in the art, in practice TLS requires a TCP connection tooperate reliably; it cannot operate properly over UDP.

In contrast to TCP, UDP is a connectionless transport protocol i.e. itis stateless in the sense that two devices can communicate using UDPwithout requiring any transport layer state to be maintained at eitherdevice, and without any associated transport layer handshakes. That is,UDP eliminate the TCP handshake. This makes UDP faster in somecircumstances, the trade-off being that UDP is unreliable in the sensethat delivery of UDP datagrams cannot be guaranteed: it provides nomechanism to tell a device, which has transported a UDP datagram,whether or not it has been successfully received (in contrast, TCPprovides a system of acknowledgements and retries). This means thatreliability, if desired, must be implemented elsewhere.

A modification of the TLS protocol, known as datagram TLS (DTLS) hasbeen developed, with a view to allowing SIP and other protocols, such asRTP, to operate over DTLS and UDP—as illustrated in FIG. 1B. DTLSoperates between the application layer 118 and transport layer 116 inthe same way as TLS. As noted above, DTLS defines a handshake and astate machine. Thus, although DTLS operates over a connectionlesstransport protocol (UDP)—meaning there is no transport layer connectionbetween the client device 102 and server 110 as such—when operatingaccording to DTLS, a DTLS connection 117′ between the client device 102and server 110 is established by the DTLS handshake, and defined by DTLSstate held at the client device 102 and/or server 110.

SRTP/SDES (secure RTP using Security Descriptions) is a known protocolthat uses a secure signaling means (including secure connections) toexchange keys for encrypting UDP audio/video traffic; it's appliedspecifically to media (not signaling) and is not stateless: both partiesstore the encryption key for as long as the session remains active.

In embodiments of the present subject matter, the secure connection usedto pre-negotiate the session key data is a secure transport layerconnection established between the initiating device and the respondingdevice via the network 108. That is, a secure, end-to-end connection atthe transport layer 114. That is, an end-to-end TCP secured using a TLSkey. Accordingly, a first TCP handshake is performed between theinitiating device and communications controller the at the start of thepre-establishment phase to establish the TCP connection, and a secondTLS handshake is performed between the initiating device and thecommunications controller to negotiate the TLS key used to secure thisconnection. This TLS handshake creates a TLS session between theinitiating device and the communication controller, in which the sessionkey data is negotiated.

Both handshakes require several network round trips, but because this isperformed in the pre-establishment phase before the communication eventis instructed (e.g. by the user of the initiating device), it does notincrease the call set up time.

Note that this TLS key is separate and different from the session keydata that is negotiated via the secure connection when established. Thatis, the TLS key is used to secure the session key negotiation messages,but it is not part of the session key data obtained as a result. The TLSkey is used exclusively for the TLS session between the initiatingdevice and the communications controller i.e. once this TLS session hasbeen terminated, it is not used again. By contrast, the session key dataobtained during this TLS session persists, and is used, after this TLSsession has been terminated (in the communication event establishmentphase)—up to several days after the TLS session has ended in someembodiments.

The TLS connection is terminated once the session key data has beenobtained, and before the communication event establishment phase—up toseveral days before in some embodiments. The session key data isretained in the memory so that it can be used to encrypt payload duringthe communication event establishment phase. This reduces the amount ofnetwork and processing resources requires, as compared with existingtechniques that rely on keeping a background TLS connection aliveconstantly.

The communication event establishment request is not sent via a securetransport layer connection—rather, security is provided by encryptingits payload using the pre-negotiated session key data.

In the described embodiments, the communication event establishmentphase is connectionless where possible. That is, not only is thecommunication event establishment request not sent via a securetransport layer connection, where possible it is not set via anytransport layer connection at all i.e. it is transmitted using aconnectionless transport protocol, such as UDP. In the case that aconnectionless transport protocol cannot be used for some reason, therequest is sent via an unsecured transport layer connection, using aconnection-oriented transport protocol, e.g. via a TCP connection orunsecured HTTP connection. Although a handshake is needs to establishthe TCP/HTTP connection, no TLS handshake is needed to secure it, whichstill represents a call set up time saving.

In some of the embodiments described below, the session key data that isnegotiated in the pre-establishment phase comprises:

-   -   an unencrypted version of a session key (or a pair of secrets        that can be used to generate it)—this is (these are) transmitted        via the secure channel; and    -   an encrypted version of the session key, which has been        encrypted using a wrapper key available to the communications        controller. This can be transmitted via the secure channel,        though that is not essential as it is already encrypted.

An additional effect provided in these embodiments is:

-   -   (iv) allowing stateless operation of the communications        controller, in the sense that no session keys need to be stored        at the communications controller at all.

The wrapper key is only accessible to the communications controller—itis never sent to the initiating device. The initiating device cannotdecrypt the encrypted version of the session key—it effectively storesit on behalf of the communications controller. The unencrypted sessionkey, negotiated in the pre-exchange phase via the secure channel, isused by the initiating device to encrypt message payloads. The encryptedversion of the session key is included in each message sent in the latercommunication event establishment phase, along with the encryptedpayload, and sent to the communications controller form the initiatingdevice. This allows the communications controller to decrypt the sessionkey using the wrapper key, and then decrypt the payload itself using thedecrypted session key. Thus all the communications controller needs toretain is the wrapper key.

No security measures beyond the encryption based on the pre-negotiatedsession key data are needed in the communication event establishmentphase- the encrypted session key can be safely transmitted from theinitiating device to the communications controller using non-securemeans—e.g. using UDP, or via an otherwise unsecured TCP e.g. HTTP/TCPconnection—as it is already encrypted with the wrapper key. Note that“otherwise unsecured” connection in this context means a connectionwhich is not secured using any means other than the encryption ofmessage payloads based on the pre-negotiated session key data (e.g. TLS,for example HTTPS).

Because the initiating device retains the encrypted session key andsends a copy in each message, there is no need for the communicationscontroller to store its own copy. This reduces the amount of back-endstorage that is needed to implement the communications controller, andprovides additional security as it avoids the need for any centralsession key repository at the communications controller (thecommunications controller will generally serve numerous client devices,and in this case the only copies of the session keys that exist are theencrypted versions distributed amongst the client devices).

In others of the embodiments described below, the session key data thatis negotiated in the pre-establishment phase comprises:

-   -   an unencrypted version of a session key (or a pair of secrets        that can be used to generate it)—this is (these are) transmitted        via the secure channel; and    -   an identifier (ID) of the session key.

In these embodiments, the communications controller does retain aversion of the session key itself, in association with the identifier.The operation is similar in these embodiments—however, in this case thesession key ID is included in each message sent in the latercommunication event establishment phase with the encrypted payload, inplace of the encrypted session key. Again, no secure connection isneeded in the communication event establishment phase—the session key IDcan be safely transmitted from the initiating device to thecommunications controller using non-secure means (e.g. using UDP, or viaan otherwise unsecured TCP connection), as the session key identifier IDitself cannot be used to decrypt the payload.

For the avoidance of doubt, note that the term “unencrypted” as usedherein (including in the Claims) refers only the wrapper key, and doesnot exclude other types of encryption. That is an “unencrypted versionof a session key” means a version not encrypted with the wrapper key,and thus includes session keys encrypted by other means provided thisencryption is reversible by the initiating device.

The session key identifier may be generated by the communicationscontroller and transmitted to the initiating device, or the initiatingdevice may generate the session key identifier and transmit it to thecommunications controller, for example the identifier may be a GUID(globally unique identifier), in the pre-establishment phase.

In the embodiments described below, the communication eventestablishment request—sent in the communication event establishmentphase—identifies the responding device, whereby transmitting thecommunication event request to the communications controller causes thecommunications controller to decrypt the encrypted request payload andtransmit a communication event invite to the responding deviceidentified in the decrypted payload.

The pre-negotiation may for example be performed during an installationof a communication client on the initiating device, as part of theinstallation process; when the communication client is first run on aprocessor of the initiating device; and/or according to predeterminedsession key negotiation schedule, e.g. such that fresh session key datais obtained, say, once a day or every few days. In some embodiments, thesession key data is retained after the communication event hasterminated, and reused for one or more later communications events. Thatis, the same session key data may be used for multiple communicationevents. The session key data is used to encrypt a request payload of thecommunication event request transmitted from the initiating device tothe communications controller during the communication eventestablishment phase. The communications controller is able to decryptthe encrypted request payload, allowing the communication event betweenthe devices to be established based on the decrypted payload.

The communication event establishment request is transmitted in directresponse to the communication event establishment instruction. For UDP(no handshake), this means the very first packet to be transmitted fromthe initiating device to the communications controller following thecommunication event establishment instruction is a UDP datagramencapsulating at least part of, and in some cases the entirety of, therequest (as no e.g. DTLS handshake is necessary). For unsecured TCP, thevery first packets to be exchanged between the initiating device and thecommunications controller are TCP handshake messages—however, once theTCP handshake has been completed to establish an unsecured TCPconnection between the initiating device and the controller, the nextpacket to be sent is a TCP packet encapsulating at least part of therequest (as no e.g. TLS handshake is necessary).

The communication event establishment instruction may be instigatedmanually by a user input at the responding device, whereby thecommunication event establishment message is transmitted in directresponse to the user input.

In the communication event establishment phase, the request comprisingthe encrypted payload is transmitted, where possible, using anunreliable transport protocol (e.g. UDP) and, moreover, in a singledatagram of the unreliable transport protocol (e.g. single UDPdatagram), using novel compression techniques described below.

Among other things, the present disclosure provides a novel signallingprotocol based on UDP with a custom data encryption and authenticationprotocol to achieve zero-RTT (round trip time) for call initiation.

FIG. 2 shows a communication system in accordance with variousembodiments of the present subject matter. The communication systemcomprises the internet 108; a first user device 204 a operated by afirst user 202 a and executing a communication client 205 a; a seconduser device 204 b, operated by a second user 202 b and executing acommunication client 205 b; and a communications controller, which is acall controller 210 in this embodiment. The call controller may be aserver, though in the present example it is a server pool (see below).

Each user device 204 a, 204 b is connected to the internet 102 via arespective physical layer connection 209 a, 209 b that allows the client204 a/204 b to access the network 102—for example a Wi-Fi, cellular,Ethernet connection or any other form of physical connection, at thelink layer 102 of the internet 102 (specifically a physical layer of thelink layer 102, corresponding to OSI L1). Physical connections offervarious levels of security (e.g. password-protected vs open Wi-Fi)—it isassumed that this level of security is insufficient. That is, thepresent techniques do not rely on any form of link layer security.

The network 108 is a packet routed network. Packet routing is availableover that physical connection, and provided at the network layer 104 bythe routers 108. For example, using IP (Internet Protocol). Indeed, theuse of IP is so widespread that network layer 304 is often referred toas the IP layer.

To establish a call between the user devices 204 a, 204 b, variousmessages are transmitted and received between: the client 205 a and thecall controller 210, and the call controller 210 and the client 205 b ina call establishment phase (“call signalling phase”). Messages are notexchanged between the user devices 205 a, 205 b directly in the callsignalling phase in the described embodiments. Among other things, thepurpose of the call signalling phase is to negotiate media parameters,to allow audio and/or video data to be transmitted and received betweenthe clients 205 a, 205 b in a subsequent media flow phase—e.g. usingVolP (Voice over IP). No audio or video data is exchanged between theuser devices 204 a, 204 b in the call signalling phase.

Embodiments are described in the context of the first user 202 a usingtheir user device 204 a to place a call to the second user 202 b. Inthis context, the first user device 204 a is referred to as theinitiating device or calling device, and the second user device 204 b asthe responding device or callee device; the first user 202 a being acaller, and the second user 202 b being a callee.

As indicated above, prior to the call signalling phase, the callingclient 202 a—in a pre-call establishment phase—obtains session key data,used to encrypt messages sent to the call controller 110 in the callsignalling phase. The pre-call establishment phase may for example beperformed when the client 202 a is first installed on the calling device202 a, and thereafter according to a key rotation schedule (session keynegotiation schedule), e.g. once every day or once every few days.

Only two users 202 a, 202 b of the communication system are shown inFIG. 2, but as will be readily appreciated there may be many more usersof the communication system, each of whom operates their own device(s)and client(s) to enable them to communicate with other users via thecommunication network 2.

FIG. 2A shows one exemplary configuration of the call controller 210,which is a server pool in this example, equivalently referred to as aserver cluster. That is, the call controlled 210 comprises a pluralityof server 524 a, 524 b, 524 c, each connected to a load balancer 522.Three servers are shown by way of example, but the call controller maycomprise any number of servers. The servers 524 a, 524 b, 524 c may bephysical servers (i.e. different server devices) or virtual serversrunning on the same or different physical devices. For example, each ofthe servers may be a server instance on a cloud platform such as WindowsAzure. The servers 524 a, 524 b, 524 c have access to a sharedelectronic storage 526. The shared electronic storage 526 can be anyform of distributed store, which is accessible by all the servers 524 a,524 b, 524 c of the cluster/pool. Requests directed to the callcontroller 210 are received by the load balancer 602, and can bedirected to any one of the servers 524 a, 524 b, 524 c. Any one of theservers can handle any request, as they all share the same cache 528.

FIG. 3 shows a block diagram of a user device 202 (e.g. 202 a, 202 b).The user device 202 is a computer device which can take a number offorms e.g. that of a desktop or laptop computer device, mobile phone(e.g. smartphone), tablet computing device, wearable computing device(headset, smartwatch etc.), television (e.g. smart TV) or otherwall-mounted device (e.g. a video conferencing device), set-top box,gaming console etc. The user device 202 comprises a processor 304,formed one or more processing units (e.g. CPUs, GPUs, bespoke processingunits etc.) and the following components, which are connected to theprocessor 304: memory 308, formed on one or more memory units (e.g. RAMunits, direct-access memory units etc.); and a network interface(s) 306.The user device 202 connects to the network 106 via its networkinterface 306, so that the processor 304 can transmit and receive datato/from the network 106. The network interface 306 may be a wiredinterface (e.g. Ethernet, FireWire, Thunderbolt, USB etc.) or wirelessinterface (e.g. Wi-Fi, Bluetooth, NFC etc.). Any of these components maybe integrated in the user device 6, or external components connected tothe user device 6 via a suitable external interface.

The memory 308 holds a communication client 205 (e.g. 205 a, 205 b) forexecution on the processor 304. The client 205 may be e.g. a stand-alonecommunication client application, plugin to another application such asa Web browser etc. that is run on the processor in an executionenvironment provided by the other application. The client 205 has a userinterface (UI) for receiving information from and outputting informationto a user of the device 204. The user interface may comprise, forexample, a Graphical User Interface (GUI) which outputs information viathe display 302 and/or a Natural User Interface (NUI) which enables theuser to interact with a device in a “natural” manner, free fromartificial constraints imposed by certain input devices such as mice,keyboards, remote controls, and the like. Examples of NUI methodsinclude those utilizing touch sensitive displays, voice and speechrecognition, intention and goal understanding, motion gesture detectionusing depth cameras (such as stereoscopic or time-of-flight camerasystems, infrared camera systems, RGB camera systems and combinations ofthese), motion gesture detection using accelerometers/gyroscopes, facialrecognition, 3D displays, head, eye, and gaze tracking, immersiveaugmented reality and virtual reality systems etc.

FIG. 4 gives a high level overview of when and where certain proceduresare implemented by the calling client 205 a. Some of these are knownprotocols, whereas others are novel procedures provided by the presentdisclosure. Like reference numerals in FIG. 4 denote featurescorresponding to those in FIGS. 1A and 1B.

Block 402 is shown at the application layer 308 of the calling device202 a, which represents an application layer key exchange performed bythe calling client 205 a in the pre-call establishment phase. Theapplication layer key exchange 402 is performed over TLS and TCP, asshown.

In the application layer key exchange of block 402, IP is used toestablish a logical, network layer connection 407 at the transport layer306—such as a TCP connection—for the pre-call establishment phase; thisconnection is end-to-end between the client 205 a and the callcontroller 210. The end-to-end connection 407 require times and packetroundtrips to set up, and in practice needs periodic maintenance in mostnetworks.

Over the network layer connection 407, security is added using TLS inthis example, though other types of security protocol can be usedinstead. As noted, such security protocols operate in between thetransport layer 306 and application layer 308, as shown in FIG. 4. Theseadd more network roundtrips after connection establishment, but inexchange provide confidentiality and data integrity even if theunderlying physical layer network is not secure.

A transport layer connection when secured in this way is referred to asa secure connection (e.g. TLS connection). Securing the connectionconnections involves a key exchange phase and optionally anauthentication phase as part of connection setup, which produce aconnection encryption key (e.g. TLS key) used to secure data sent overthat connection.

As noted above, some existing call signalling existing techniques arereliant on a long-lived secure connection using TLS that is—in contrastto the present subject matter—kept active for a long time, so that thecall signalling can be conducted over this connection. The connection ismaintained in the background, which requires packets to be sent everyfew minutes or seconds. Any time the underlying physical connectionchanges (e.g. when a phone switches from Wi-Fi to cellular), the TLSconnection is re-established.

The embodiments of the present subject matter described herein also setup a secure connection 407, by performing e.g. a standard TLS keyexchange, certificate validation etc., to obtain a connection encryptionkey e.g. TLS key.

The secure connection 407 is established in the pre-call establishmentphase and, instead of using this connection for the signaling itself,the application level key exchange 402 is performed over the connection407—generating another key (“session key”) and a ticket containing anencrypted version of the session key or an ID of this session key (seebelow)—these are stored in the memory 308 of the calling device 104 a,whereby the client 205 a can access them as and when it seems them toinitiate call signaling. The secure connection 407 is then torn downonce the session key has been obtained. That is, the connection 407 isnot maintained it or kept it active after the session key has beenobtained—this means there is no background traffic and no battery drain.

For the avoidance of doubt, it is once again noted that the “connectionencryption key” (e.g. TLS key) is separate and different from the“session key” used in the call signalling phase. The connection 407,once secured with the connection encryption key, is used topre-negotiate the session key; but it is the obtained session key thatis used to encrypt messages in the call signalling phase, by which timethe connection 407 has been torn down to save resources. Once theconnection 407 has been torn down, the connection encryption key becomesredundant and can be discarded entirely.

Block 404 in FIG. 4 is also shown at the application layer 308 of thecalling device 202 a, and represents a novel call signaling procedureperformed by the client 205 a, at a later time, in the call signalingphase based on the pre-negotiated session key obtained through theapplication layer key exchange of block 402. The process of block 404comprises, in response to a call establishment instruction (e.g.instigated by the caller 202 a selecting an option via the UI of theclient 205 a to call the callee 202 b) using the pre-negotiated key andticket, in combination with a connectionless transport protocol such asUDP, to send and receive encrypted messages between the client 205 a andthe call controller 210.

UDP is built directly on top of IP, and therefore can function as soonas the physical connection is available; there is no need to establishtransport layer connections for it. Where e.g. UDP is unavailable, aninsecure network layer connection (TCP or a higher-level protocol suchas HTTP) can be used instead of UDP. Messages are encrypted in the sameway using the pre-negotiated session key—which provides a form of secureconnections that require no additional roundtrips on top of what'sneeded to establish the standard insecure transport layer connection(e.g. TCP without TLS, e.g. HTTP rather than HTTPS). UDP may beunavailable when user's network environment blocks UDP communication forone of a number of reasons, or effectively unavailable due to extremepacket loss in very poor network conditions.

Block 406 shown at the application layer 308 of the initiating device202 a represents media data exchange processes, which may be used afterthe signaling phase has completed to transmit and receive audio and/orvideo data between the caller client 205 a and the callee client 205 b,based on media parameters negotiated during the call signaling. Forexample, based on VoIP using UDP.

FIG. 5A shows a signaling diagram for a pre-call establishment phaseaccording to a first embodiment, in which the application layer keyexchange of block 402 is performed periodically in the background toestablish a shared “session key” a shared key which will be used duringcall setup. The most recent session key remains valid until the nexttime the procedure is performed.

At step S502, the TLS connection 407 is established between the client205 a and the call controller 210.

At step S504, the client 205 a requests a session ticket form the callcontroller 210. In response, the call controller 210 generates a sessionkey, which is a 256-bit cryptographically strong random sequence(“SessionKey”).

At step S506, the call controller 210 requests, from a key store 500implemented in the shared memory 526, a current wrapper key(“WrappingKey') and a wrapper key identifier of the current wrapper key(“WrapperKeyID”).

At step S510, the call controller 210 encrypts the SessionKey withWrappingKey, using AES-256 in CBC mode (though in other implementations,a different algorithm may be used) with a zero initialization vector(IV), and creates a ticket (”Ticket') comprising WrapperKeylD and theencrypted SessionKey. The ticket may also comprise a version identifier(“Ticket Version”), denoting a current version of the signalingprotocol, to provide support for new versions.

At step S512, the call controller 210 sends to the client theSessionKey, a current server timestamp, and Ticket. That is the callcontroller 210 sends both the encrypted version of the session key (inthe ticket) and an unencrypted version of the session key for use by theclient 205 a. At least the unencrypted version of the session key istransmitted via the secure TLS connection 407, and in this embodiment sois the ticket and the server time stamp. The connection 407 is torn downonce these have been received at the client 205 a. The server time stampdenotes a current time as measured at the call controller 210.

At step S514, the client 205 a computes a time difference between theserver time and a current client time. The client 205 a storesSessionKey, Ticket and the computed time difference in the memory 308,where it remains for use as an when it is needed in later callsignaling.

SessionKey is only used to protect the communication of one client (i.e.205 a) with the call controller 210. The call controller 210 is acentrally-managed entity, and can be trusted to choose SessionKeywithout any security risk. Ticket is completely opaque to the client 205a, as the client 205 a never has access to Wrapper Key.

A validity period of Ticket is determined by a WrappingKey rotationschedule and is e.g. on the order of several days. The validity periodis determined by security restrictions applicable in the communicationscenario. For example, in a military embodiment, it may be of the orderof hours, rather than days.

At the end of the validity period, WrapperKey is destroyed completelye.g. after a few days (or less, depending on the circumstances), theserver will not have access to key material necessary to unwrap contentsof the Ticket, thus rendering Ticket unusable. One way of ensuring thatthe wrapper key can be deleted permanently is storing it only involatile memory (permanency of deletion from volatile memory isguaranteed, unlike non-volatile memory, which is susceptible to dataretrieval methods to restore deleted data). This provides forwardsecrecy for the call signaling (i.e. historic call signaling messages,even if nefariously recorded, can never be unlocked once the wrapper keyhas been deleted).

The complete destruction of WrapperKey at the end of the validity periodcan be ensured by only ever storing it in volatile memory. Thus, in someimplementations, at least part of the key store 500 is implemented involatile memory. That is, at least a portion of the shared electronicstorage 526 may be in-memory storage (i.e. volatile memory), in whichthe wrapper key can be held.

The client can reuse the same Ticket for multiple calls, if it chooses arandom IV for each message (see below). As is known in the art, aninitialization vector (IV), sometimes referred to as a startingvariable, is an input to cryptographic algorithm that providesuniqueness. A fundamental property of an IV is that it is unique for agiven key. That is, no IV is used twice for the same key. Often an IV israndomized, i.e. random or pseudorandom, though depending on thecryptographic algorithm that is not always essential.

Alternatively, the client 205 a may invalidate (destroy) Ticket aftereach call/session, and obtain a new one in preparation for the nextcall, in another pre-establishment phase performed before that next callis instructed. This mechanism renders it even more difficult for theattacker to gain anything of value by observing packets.

The Ticket may persist in the memory 308 even if the execution of theclient 205 a is terminated, and even if the initiating device 204 a ispowered down. Alternatively, the process of FIG. 5A may be performedeach time the client 205 a is executed i.e. each time a new instance ofthe client 205 a is created on the processor 304.

FIG. 5B shows a signaling diagram for a subsequent call signalingprocess.

To communicate with the call controller 210 client performs followingsteps.

At step S516, the client 205 a loads Ticket, SessionKey, and timedifference from the memory 308.

At step S518, the client 205 a generates request contents, whichcomprises:

-   -   a random request identifier (“RequestID”);    -   A current timestamp (“TimeStamp”) denoting a local current time        measured at the calling device 504, adjusted for the difference        between client and server time;    -   a user authentication token for the user 202 a; and    -   a request message payload (“RequestPayload”).

At step S520, the client 205 a uses a key derivation function (KDF) toderive an encryption key (“EncryptionKey”) from SessionKey. That is,from the unencrypted version of the session key. Any suitable keyderivation function can be used to this end. The client 205 a generatesa cryptographically strong random 128-bit/V and encrypts the requestcontents using AES in CBC mode with initialization vector set to IV andthe key set to EncryptionKey. This results in an encrypted ciphertextstring (“Encrypted'). Note, as with the encryption of step S510, otherimplementations may use different cryptographic algorithms here, whilefollowing the flows described in this document.

The client 205 a also derives a separate authentication key(“AuthenticationKey”) from the session key using the KDF, concatenates[Ticket, IV, Encrypted], and computes a HMAC (“HMAC”) as HMAC-SHA256 ofthe concatenated [Ticket, IV, Encrypted] string with the key set toAuthenticationKey. As is known in the art, HMAC means a keyed-hashmessage authentication code, and provides integrity protection ofmessages i.e. they can be used to determine when a massage has beentampered with or otherwise altered without decrypting it.

At step S522, the client 204 a sends a request message comprising:

-   -   Ticket,    -   IV,    -   Encrypted, and    -   HMAC to the server.

That is, all four elements are included separately in the requestmessage.

At step S524, the call controller 210 extracts WrapperKeylD from theTicket, and obtains WrappingKey corresponding to WrapperKeylD from thekey store 500 (S526) implemned in the shared cache. If there's no suchkey, then no further processing is performed and no error message sent.There may be no such wrapper key, for example, if the validation periodhas ended and the relevant wrapper key permanently deleted accordingly.

At step S528, the call controller 210 obtains SessionKey by decryptingthe encrypted session key in Ticket with the WrappingKey obtained atS526.

The call controller 210 then derives EncryptionKey and AuthenticationKeyfrom the decrypted SessionKey, and verifies the HMAC value by computingan expected HMAC using its own AuthenticationKey derived fromSessionKey. If the expected HMAC does not match the HMAC of the requestmessage received from the client 205 a, no further processing isperformed and no error message is sent.

If the expected HMAC does match the request HMAC, at step S530, the callcontroller 210 proceeds to decrypt Encrypted using AES in CBC mode withinitialization vector set to IV and key set EncryptionKey (S523).

The call controller 210 then reads the descripted TimeStamp, and dropsthe drops request message if TimeStamp differs from a current timemeasured at the server by more than a first time interval (T1). Asnoted, TimeStamp was generated by the client 205 a taking into accountthe time difference between the client 205 a and the call controller210.

The call controller 210 comprises a response caching message handler211, which maintains, in the shared memory 526, a shared cache of recentprocessed requests covering a second duration (T2) i.e. the last T2seconds, and drops request if its RequestID is already in this memory,where T2>=T1. When multiple copies of the request are sent (forreliability—see below), the RequestID can be used to ensure that onlyone is acted upon and duplicates are discarded.

At step S534, provided the request was received within T1 and there isno request with RequestID already in the shared memory, the callcontroller 210 processes the decrypted request contents, includingRequestPayload and—provided certain timing constraints are met (seebelow)—generates a response message (“Response) comprising RequestIDfrom the request contents, Timestamp, and a response message payload(”ResponsePayload). Including RequestID in the response allows theclient 205 a to distinguish between multiple copies of the response,which may be sent for reliability (see below).

The call controller 210 also generates cryptographically strong random128-bit/V and encrypts Response using AES in CBC mode withinitialization vector set to IV2 and key set to EncryptionKey. Thisresults in another encrypted cipher text string (“Encrypted2”). The callcontroller 210 computes another HMAC (“HMAC2′) as HMAC-SHA256 of [IV2,Encrypted2]. The call controller 210 then sends HMAC2 and Encrypted2 tothe client (S536).

The client 205 a authenticates and decrypts data in the same manner.

All Requests contain a user authentication token, which authenticatesource of request.

Replay protection is based on the following.

The call controller 210 utilizes shared ephemeral storage (e.g. Redis)to keep necessary number of recent WrappingKey-s. Each server of thecall controller 210 is provisioned with asymmetric keypair (RSA, 2048bits). WrappingKey in ephemeral storage is encrypted with servers'public key (RSA-OAEP padding). Network access to ephemeral storage isvia TLS only and authentication is based on either client TLScertificates or Azure Active Directory (for example). Additionally,there is a dedicated mechanism for automatic and periodic scheduled keyrotation. Service performing key rotation encrypts newly generatedcryptographically secure random 256-bit key using servers' public keyand places result into ephemeral storage. It can also optionally notifyservers about key rotation or servers can notice this on their own byperiodically polling ephemeral storage. Keys may for example be rotatesevery one to four hours and, maintaining those keys covering the last 7days.

Note: no attempt is made to explicitly authenticate the Ticket value.The decrypted SessionKey is immediately used—in form of the derivedAuthenticationKey—to validate the HMAC on the request ciphertext. If theTicket has been modified, HMAC verification will fail and the key willnot be used to decrypt the message body. If the message HMAC check ismodified in the future, special measures must be taken to ensure thatthe decrypted Payload is authenticated before using it.

In a variation of the first embodiment, ticket acquisition is performedahead of time and is runs over a proper TLS connection between clientand server. The process comprises the following steps:

-   -   1. The client 205 a generates 256-bit cryptographically strong        random sequence (ClientSecret) and sends in to the call        controller 210 (over TLS connection 407).    -   2. The call controller 210 generates 256-bit cryptographically        strong random sequence (ServerSecret), and XORs it with        ClientSecret to obtain SessionKey.    -   3. The call controller 210 obtains current WrappingKey and its        WrapperKeyID.    -   4. The call controller 210 wraps (i.e. encrypts) SessionKey        using WrappingKey and creates a Ticket containing KeylD and        wrapped SessionKey.    -   5. The call controller 210 sends to the client 205 a        ServerSecret, current server timestamp, and Ticket (over the TLS        connection 407).    -   6. The client 205 a computes SessionKey by XORing ClientSecret        and ServerSecret, computes time difference between server time        and current client time; it then stores SessionKey, Ticket and        computed time difference.

That is, in the second embodiment, SessionKey is computed by combiningentropy from both parties to protect from potential problems.Thereafter, the subsequent call signaling phase proceeds in the samemanner.

The above steps are performed for each request and response exchangedbetween the client 502 a and the call controller 210.

As shown in FIG. 5C, for the first request sent from the client 205 a tothe call controller 210, the RequestPayload identifies the respondingdevice 204 b. For example, it may comprise a user identifier of thesecond user 202 b, a device identifier or network address of the seconddevice 204 b, or any other identifier that allows the call controller210 to identify the responding device 204 b. The first request istransmitted in direct response to a call establishment instruction S520received by the initiating client 205 a, for example from the caller 202a. Subject to steps S524-S534 set out above, the call controller—inaddition to the transmitting a response to the caller client 205 a atstep S536—also transmits a call invite (at step S538) to the client 205b on the responding device 204 b identified in the payload of the firstrequest. This causes the responding client 205 b to enter a ringingstate (S540) to notify the callee 202 b of the incoming call.

A feature of the key exchange mechanism of block 402 in the firstembodiment is that it's stateless on the call controller 210: the callcontroller 210 does not need to store the session keys or any per-userdata; all it needs is the wrapper key which is independent of the user.This allows the key distribution server to easily scale to large numbersof users.

In a second embodiment, the call controller 210 does store its ownversion of the session key. Rather than sending an encrypted session keyto the client, the client 502 a or the call controller 210 generates asession key ID of the session key, e.g. GUID (Globally UniqueIdentifier), and the session key ID is used in place of the encryptedversion of the session key in the Ticket.

The version of the session key stored at the server may be an encryptedversion (encrypted with the wrapper key), in which case forward secrecycan be provided by storing the wrapper key in volatile memory only, sothat once the wrapper key is deleted form the volatile memory theencrypted version of the session key becomes permanently unusableirrespective of where it is stored. Alternatively, the version stored atthe server may be an unencrypted version, in which case forward secrecycan be provided by storing the unencrypted version of the session key involatile memory only, so that it can be deleted permanently.

As noted, the techniques described above provide:

-   -   Authentication-both at the user level—with the user tokens—and        at the message level—through the integrity protection provided        by the HMACs.    -   Confidentiality-it is not be possible to identify the callee or        read session parameters by observing the packets, or extract the        media encryption keys carried by them, because of the encryption        based on the session key. Moreover, forward secrecy is        preserved.

UDP is preferred in this context, as it provides the fastest signallingdue to the absence of handshakes. However, as noted, it isunreliable—the techniques set out below compensate for this using acombination of data compression and protocol fall back.

2) Data Compression and Protocol Fallback

In addition to the above encryption, a combination of data compressionand protocol fall back is used to ensure reliability—even when anunreliable transport protocol such as UDP is used. That is, to ensurethat signalling can function in the presence of moderate packet loss, orin the case UDP connectivity is completely unavailable.

UDP fragmentation is not always available (e.g. it is unavailable inWindows Azure). When UDP fragmentation is unavailable, it is up to adeveloper to implement their own application-level message fragmentationand reassembly mechanism would be needed. This is cumbersome andresource-intensive, however the present techniques obviate the need forthis by compressing each message to fit it in a single UDP datagramwhenever possible, so that no application layer fragmentation andreassembly mechanism is needed. The path MTU (Maximum Transmission Unit)defines the maximum size of message that can be encapsulated in a singleUDP datagram.

In the event that:

-   -   UDP is not available (e.g. due to UDP blocking in a firewall),        or    -   any message cannot be compressed to fit into a single UDP packet        the system falls back to a non-preferred protocol for        signalling, for example:    -   TCP, e.g. HTTP/TCP.

To deal with packet loss when using UDP, every request and response istransmitted multiple times, e.g. 2-3 copies of each request and eachresponse may be transmitted. The RequestlD described is used todeduplicate requests and avoid processing them multiple times; responsesare always matched to a table of outstanding requests in the sharedstorage 526 so duplicate responses will be automatically ignored.

If a request times out over the preferred protocol, e.g. UDP, the client205 a will automatically retry transmitting the same request using thenon-preferred protocol, e.g.:

-   -   TCP, e.g. HTTP secured using the pre-negotiated session key        data—at the cost of a TCP handshake to establish a TCP        connection.

TCP can be used without TLS when the above described encryptiontechniques are used, e.g. over HTTP without additional encryption, asthe message payload is already encrypted using the pre-negotiatedsession key. In other implementations, however, it may be appropriate tofall back to TLS e.g. HTTPS, at the cost of a TCP handshake and anadditional TLS handshake.

Alternative implantations may establish an e.g. TLS connection inparallel with the UDP signaling every time as a fall back. In this case,the cost of the handshake is only incurred if the TLS channel wasn'tready by the time of the protocol change. In normally circumstances,this would generally be wasteful (and bandwidth competing), and maychoke the network available to device if the network conditions areconstrained. Nevertheless, it may be appropriate in some limitedcircumstances.

The response caching message handler 211 of the call controller 210 willallow the client to retrieve the response on the retry if it waspreviously lost—irrespective of the transport layer protocol used tosend it. The message handler 211 is configured so that, when a fallbackfrom UDP to HTTP(S) occurs, in the event that the original UDP messagedid reach in fact the server, then the server will correctly understandthe HTTP message to be a retry, and respond with the same response thatit would have sent over UDP, appropriately transforming it to be a validHTTP payload if needed. In other words, the message handler 211 isconfigured to identify messages as duplicates of one another (based onthe request IDs) irrespective of the transport protocol over which theywere sent. The call controller 210 will attempt to respond to a requestusing the preferred protocol (e.g. UDP) unless it is unable to do so dueto the size of the repose (see below) or until a duplicate of thatrequest is received using the non-preferred protocol—in response toeither event, the call controller 210 will fall back to thenon-preferred protocol (e.g. HTTP(S)).

2a) Protocol Fallback

In the described embodiments, call setup time is reduced on average byusing UDP for the initial communications signaling phase wheneverviable, with robust fallback mechanism to ensure minimal disruptionwhenever call signaling over UDP is not viable.

UPD is connectionless and thus inherently faster thanconnection-oriented TCP because UDP forgoes the time-consuming handshakeneeded to establish a TCP connection. However, UDP is also unreliable,in the sense that safe receipt of a transmitted UDP datagram cannot beguaranteed. This is because UDP also forgoes the built-inacknowledgement and retry mechanisms of TCP that make TCP a reliableprotocol.

In many contexts where UDP is currently used, this unreliability isacceptable. For example, where transmitting audio or video data over UDPto a receiving device in the subsequent media flow phase of a call, itis acceptable for some audio and video data to be irrevocably lost intransit, provided the amount of distortion this creates in theaudio/video output at the receiving device is tolerable to a user.

However, the preceding call signaling phase is fundamentally differentto the media flow stage—in this context, it is critical that at leastone copy of every call signaling message makes it to the intendedentity, be that the initiating device, responding device or callcontroller. If any message is lost altogether, the call signaling phaseis liable to be delayed significantly or even fail altogether, unlessmessage loss is properly handled. For this reason, TCP is often favoredfor call signaling, and is the most commonly used transport protocol forSIP.

The present disclosure recognizes that, without proper management, theinherent fastness of UDP will not translate into reduced call set-uptimes in all real-world scenarios. That is, the present disclosurerecognizes that one cannot simply perform call signaling over UDP in theglib expectation of universally reduced call set up times: whilst inmany circumstances, performing call signaling over UDP is viable andwill result in significantly reduced call set up times due to itsinherent fastness, there are other circumstances in which attemptingcall signaling over UDP is not viable, i.e. because it couldsignificantly increase call set up times or cause call signaling to failaltogether - leading to a poor user experience.

Accordingly the present disclosure provides various mechanisms to, onthe one hand, ensure that UDP is used for call signaling whenever viable(resulting in faster call setup) and, on the other hand, quicklydetermine when UDP is not viable to prevent significant increases incall set up times or failure of call signaling in that event.

In the described embodiments, call signaling is always attempted usingUDP initially—however, several levels of robustness are built into thesystem to balance the benefits of UDP signaling, in terms of reducedcalls setup times, with its potential pitfalls:

-   -   A first level of robustness can optionally be provided by        message duplication, whereby multiple copies of a message are        re-transmitted repeatedly in very quick succession (of order        every ˜100 ms) using UDP. This makes the call signaling robust        to light-to-moderate UDP datagram loss. In many circumstances,        this first level of robustness is sufficient to ensure that call        signaling can be successfully completed over UDP, with        significantly reduced call set up times as a result.    -   A second level of robustness is provided by fast protocol        fallback based on provisional responses (acknowledgements),        transmitted at the application layer in the described        embodiments. These allow the callee device to make a very fast        provisional check as to whether or not UDP is viable for a given        call signaling. A provisional response is transmitted by the        call controller to the caller device in immediate response to a        request from the caller device, before it has finished        generating a final response, such that under normal conditions        the initiating device can expect a provisional response to any        request is sends within a short time interval, e.g. about 1-2        seconds. If no provisional response is received within this        short time interval (e.g. due to heavy packet loss or UDP        blocking, for example), the caller device can immediately fall        back to reliable TCP and re-transmit its request over TCP. In        this situation, the call set-up time is increased—but only        marginally i.e. by about 1-2 seconds.    -   If a provisional response is received in this short time        interval, the initiating device provisionally concludes that UDP        is viable, and continues with UDP. A third level of robustness,        which is effectively a fail-safe mechanism, ensures that the        initiating device can still fallback to reliable TCP in a        reasonably timely fashion (of order 10-15 seconds) in that        event, should it transpire that UDP is not viable.

Whilst TCP and UDP are used herein as examples of preferred andnon-preferred networking protocols, the disclosure is not limited inthis respect and the underlying principles of the present teaching applymore generally to other networking protocols. In this respect, the term“preferred networking protocol” refers generally to any networkingprotocol at any network layer, according to which session-basedcommunications are initially attempted but which is liable to fail incertain circumstances. The term “non-preferred protocol” refersgenerally to any networking protocol that can substitute the preferredprotocol and that is more likely to succeed in at least some of thosecircumstances.

A preferred protocol may for example be any connectionless and/orunreliable transport protocols, and a non-preferred protocol may forexample be any other connection-oriented and/or reliable transportprotocol, though the present teaching is not limited to this.

FIG. 6 shows a flow for a method of sending a request from the client205 a to the call controller 210.

At step S602, the client 205 a generates a request comprising anencrypted payload for transmission to the call controller in accordancewith steps S516-S520 of FIG. 5B, and transmits it to the call controller210 as in step S522 of FIG. 5B.

At step S604, the initializes in the memory 308;

-   -   a retry transmission timer, and    -   a protocol fallback time, initially set to a longer starting        time interval than the retry transmission timer.

The timers count down, and expire at the end of their respective timeintervals. In this manner, the client 205 a, from the sensing of arequest in a UDP datagram, monitors an elapsed time since itstransmission.

For example, the retry transmission timer may be set to approximately100 ms, and the protocol fallback timer initially to e.g. approximately1-2 seconds, though in some circumstances less than 1 second may beappropriate.

If and when the retry timer expires (S606), the client 205 a retransmitsthe request using the preferred protocol (S608).

If and when the protocol fallback time expires (S612), the clientretransmits the request according the non-preferred protocol e.g. TCP,e.g. HTTP/TCP (S616).

To speed up the fallback to the non-preferred protocol (e.g. TCP, e.g.HTTP), two special messages are used in addition to the request andresponse messages:

-   -   a provisional acknowledgement (provisional response)—sent by the        call controller 210 as soon as it receives a UDP datagram        containing a request from the client 205 a. This is sent in        parallel with commencing the request itself, before the        processing has completed and irrespective of whether the request        is accepted or rejected.    -   a fast fall back message—sent by the call controller 210 if it        cannot fit its response to the client's request into a single        UDP packet.

Both of these special messages, just like request and response messages,are transmitted multiple times with a small interval (e.g. ˜100 ms) forreliability.

The provisional acknowledgement packet indicates to the client 205 thatthe request was received, and serves two functions. If and when aprovisional acknowledgment of the client's request is received at theclient 205 a (S608), the method proceeds to step S610, at which theclient 205 a halts the request retransmission timer, ensuing that nomore retires are attempted using the preferred protocol (e.g. UDP)—nomore duplicate request packets are needed using UDP as the client nowknows the call controller 210 had received one, and therefore knows thatit is able to send UDP messages to the call controller 210.

Simultaneously, at step S611, the client 205 a extends the protocol fallback timer. If the provisional acknowledge was not received in a shorttime (e.g. 1-2 seconds or <1 second), the client will fall back to thenon-preferred protocol (e.g. TCP, e.g. HTTP/TCP) under the assumptionthat UDP connectivity is not working. This fall back timer is shorterthan the maximum server side processing time for certain requests, soreceiving the provisional acknowledgement increases the client'sconfidence in UDP connectivity and lengthens the timer to the typicalvalues used for HTTPS timeouts (e.g. to 10-15 seconds). This means thatthe client will now wait for longer before falling back to thenon-preferred protocol at S612.

The fact that a provisional acknowledgment has been received means theclient can be sure that at least one of its UDP requests has beenreceived at the call control 210. However, that does not guarantee thata full, i.e. non-provisional, response will make it from the callcontroller to the client, as the full response is also being sent by thecall controller using unreliable UDP. For example, more severe packetloss may be experience in the direction from the call controller to theclient for whatever reason, or some form of one-way UDP blocking may bein place between the client and the call-controller. The extended timertherefore provides a fail-safe—if the extended timer expires, the clientwill re-sent a copy of the request via e.g. HTTP(S) which, as notedabove, will in turn cause the call controller 210 to fall back toHTTP(S) and resend its final response via HTTP(S), such that its arrivalis guaranteed at the client due TCP's built-in retry mechanisms.

If at any time a fast fall back message is received from the callcontroller 210 (S614), the client 205 a, upon receiving the fast fallback request message, immediately stops all timers and retries therequest using the non-preferred protocol (e.g. TCP, e.g. HTTP/TCP). Thisallows the call controller 210 to retrieve the response, which isalready cached in the response caching message handler of the callcontroller 210.

If at any time a full response is to the client's request is received bythe client 205 a (S618 a), the client 205 a halts all timers, as itknown the response has now been received and processed by the callcontroller 210.

2b) Data Compression

To avoid implementing a complex application layer reassembly mechanismand potentially reducing reliability, every request and response isencapsulated where possible in a single UDP packet which is smaller thanthe most commonly observed path MTU values (e.g. 1200-1400 bytes).Certain requests are fairly large, a specialized compression scheme isused to compress them—such as Deflate (GZIP) with a custom, pre-defineddictionary (“compression dictionary”). That is, a known compressionfunction is used with a custom, pre-defined compression dictionary.

FIGS. 8A and 8B illustrate the operation of an exemplary compressionfunction, represented by block 802. FIG. 8A shows how the compressionfunction 802 may operate without a pre-defined dictionary. In this case,the compression function, in generating a compressed version of themessage 814, identifies matching character strings in an input message804 inputted to the compression function 802. Each time a characterstring—“xyz” and “abc” in this simplified example—is repeated later inthe message, the repeated string is replaced with a reference to thefirst occurrence of that string—in this example “[#1]” and “[#2]” denotereferences to the first occurrence of “xyz” and “abc” in the compressedmessage 814. As will be readily appreciated, replacing strings withreferences in this manner can reduce the size of the message by avoidingduplicate encoding.

FIG. 8B demonstrates how the compression function can operate based onthe pre-defined compression dictionary 216 to achieve a greater sizereduction. In this example, the dictionary 216 is shown to comprise, byway of example, the character strings “xyz” and “abc”, allowing eachoccurrence of these strings in the compressed message 214′-including thefirst occurrences—to be replaced with references to the correspondingstring in the dictionary 802—denoted “[#1′]” and [#2′]” respectively.Another device with access to a matching dictionary can decompress themessage 214′ using the matching dictionary. The compression function 802is implemented by the clients and the call controller 210, which alsoimplement corresponding decompression functions. Thus compressedmessages can be communicated between the clients and the call controllerin both directions.

A compression function that operates in this manner is sometimesreferred to in the art as dictionary coder or, equivalently, asubstitution coder compression function.

Returning to FIG. 2, FIG. 2 also shows a dictionary server 212 and adictionary data store 214 connected to the network 106. The dictionarydata store holds, in an addressable memory location of the data store214, the custom compression dictionary 216, whereby the dictionary isaccessible to the user device 204 a.

The dictionary contains one or multiple sample requests (e.g. one ormore request message templates), and helps the Deflate algorithmefficiently compress JSON and SDP as it can refer to names andsubstrings from the dictionary. This approach has demonstratedsignificantly better compression than conventional Gzip/deflate, and hasrendered this approach viable.

Whenever a request generated by the client 205 a or a response generatedby the call controller 210 is too large to fit in a single UDP datagram,even when compressed, the client/call controller falls back to thenon-preferred protocol (e.g. TCP, e.g. HTTP/TCP).

HTTPS allows for message compression under certain circumstances.However, in HTTPS, compression is something that must be negotiated aspart of the HTTPS session establishment: a client must indicate in itsinitial request which compression scheme(s) is supports if any, and aserver will, in its response to this request, indicate whether it toosupports any of these. Thus it is impossible to compress the initialrequest in HTTPS. The HTTPS response may for example include a link(e.g. URI, that is a uniform resource indicator) to a compressiondictionary for a compression scheme supported by both the client and theserver, so that the client can access the dictionary using the link tocompress its subsequent messages.

By contrast, herein a link (e.g. URL) to the custom compressiondictionary 216 is pre-distributed to the client 205 a by the dictionaryserver 212. That is, before the client 205 a has even attempted toinitiate call signaling. That is, before the communication eventestablishment instruction of step S520 in FIG. 5C has been received bythe client 205 a, e.g. from the user 202 a.

For example, the link may be:

-   -   downloaded by the client 502 a:        -   from the dictionary server 212 upon installation,        -   each time a new instance of the client 502 a is created on            the processor 304        -   periodically    -   pushed to the client by the dictionary server 212, for example        any time the dictionary 216 is updated

The client may pre-download the dictionary from the dictionary store216.

Alternatively, the dictionary itself may be pushed to the client 205 afrom the data store 214, for example any time it is updated.

An equivalent mechanism will be used by the server when sendingnotifications to the client. The server will infer the IP address andport for the client from the incoming request, and will attempt to reachthe client over UDP first, before falling back to HTTPS (e.g. via aproxy server via which the client 205 a is reachable).

Packet Format

FIG. 7 shows an exemplary application layer packets.

A plaintext (i.e. uncompressed) packet 702 is shown as comprising anapplication layer header 702 and a variable length payload. The headerconsists only a one byte type filed, denoting a type of the packet. Inthis example, there are multiple types of uncompressed packet denoted bydifferent bytes. The remaining bytes of the packet 702 constitute itspayload. Although the payload has a variable length, its length is notidentified in the header. This may be a request payload (if generated bythe client 205 a), or a response payload (if generated by the callcontroller).

A compressed packet 704, whose payload is obtained by applying thecompression function based on the dictionary 212 to the plaintext packet702. The compressed packet 704 has its own type header 705, which is setto identify it as a compressed packet. In this example, these is onlyone type of compressed packet though in other implementations multiplecompressed types may be used e.g. to denote different compressiondictionaries and/or different compression functions. Again, the payloadof the compressed packet is variable, but no length field is used.

An encrypted packet 706 is shows, whose payload comprises an encryptedversion compressed packet 704 (including its header 704), encrypted withthe session key. At least for a resist generated by the client 205, thepayload also comprises

-   -   the initialization vector    -   the encrypted version of the session key (first embodiment) or        the session key ID (second embodiment).

The encrypted packet also has its own type field 707, identifying it asan encrypted packet. In this example, there is only a single type ofencrypted packet though other implementations may define multiple typesof encrypted packet.

There is no “length” field defined anywhere—only a type filed. Theassumption is that the process starts with the entire packet, andrecursively parses it as an encrypted packet (if the type indicates so),then a compressed packet, and finally a plaintext packet. The entire UDPpacket contains only one message, potentially encapsulated multipletimes.

If multiple messages need to be sent in one packet, another envelopetype (64 for example) can be defined, which is followed by a 2-bytelength field, and then by the data that is encapsulated in the next typeof envelope.

More fields can be added (e.g. to identify the compression algorithm,etc.) if the relevant information cannot be encoded in the remainingtype values.

Replay Protection:

Replay protection ensures that an attacker resending previously capturedmessages should not be able to start another call or perform any otheraction on behalf of the client.

Important calling requests—especially the call setup request—need to beprotected against packet replay. There are two mechanisms that worktogether to prevent replay attacks on the UDP protocol:

Short Term Replay Protection:

The call controller maintains a buffer with the responses to allrequests within the last few minutes, indexed by the client-generatedRequest ID. The buffer is used primarily to provide idempotency in caseof the client retrying the request (due to a timeout or a loss ofconnectivity), but it automatically guards against replay attacks aswell. When a response is found in the buffer, it's sent out back to theclient and no action is performed. The buffer is maintained in theshared storage 526 for the cluster of server machines 524 a, 524 b, 524c, so that this replay protection strategy protections the entirecluster, and not just individual machines in the cluster (though thepossibility of individual servers maintaining their own buffer is notexcluded).

Most requests related to a single call are guaranteed to eventuallyarrive at the same machine by means of the proxy layer, which associateseach call with a specific machine.

In short, the response buffer provides short term replay protection (onthe order of 5 minutes).

Long Term Replay Protection:

When a client generates the session ticket, it also uses a date headerfrom the response to estimate the rough time difference between theclient and the server clock. All the UDP requests include a timestamp,adjusted for the time offset, and if the mismatch between the realserver time and the timestamp is larger than the response bufferduration (5 minutes), the request is discarded and a negativeacknowledgement packet is sent to the client for that request ID.

There is a possibility of false positives, if the client's clock isadjusted by more than 5 minutes in between the retrieval of the ticketand its use, but this is acceptable since the UDP protocol is just anoptimization—in that event, the client will just fall back to e.g. TCP(e.g. HTTP/TCP) after receiving a negative ACK, or after the shortfallback timeout (1-2 seconds) elapses.

As noted above, the various methods of sections 1), 2 a) and 2 b) of thepresent disclosure can be combined to achieve the effects set out above.However, the techniques are nevertheless separable. That is, forexample, the encryption techniques of 1) of the present disclosures canin other contexts be implemented without the data compression techniquesof 2 a) and/or without the protocol fallback techniques of 2 b) and viceversa.

Generally, any of the functions described herein can be implementedusing software, firmware, hardware (e.g., fixed logic circuitry), or acombination of these implementations. The terms “module,”“functionality,” “component” and “logic” as used herein generallyrepresent software, firmware, hardware, or a combination thereof. In thecase of a software implementation, the module, functionality, or logicrepresents program code that performs specified tasks when executed on aprocessor (e.g. CPU or CPUs). The program code can be stored in one ormore computer readable memory devices. The features of the techniquesdescribed below are platform-independent, meaning that the techniquesmay be implemented on a variety of commercial computing platforms havinga variety of processors. For example, the user devices (user terminals)may also include an entity (e.g. software) that causes hardware of theuser terminals to perform operations, e.g., processors functionalblocks, and so on. For example, the user terminals may include acomputer-readable medium that may be configured to maintain instructionsthat cause the user terminals, and more particularly the operatingsystem and associated hardware of the user terminals to performoperations. Thus, the instructions function to configure the operatingsystem and associated hardware to perform the operations and in this wayresult in transformation of the operating system and associated hardwareto perform functions. The instructions may be provided by thecomputer-readable medium to the user terminals through a variety ofdifferent configurations.

One such configuration of a computer-readable medium is signal bearingmedium and thus is configured to transmit the instructions (e.g. as acarrier wave) to the computing device, such as via a network. Thecomputer-readable medium may also be configured as a computer-readablestorage medium and thus is not a signal bearing medium. Examples of acomputer-readable storage medium include a random-access memory (RAM),read-only memory (ROM), an optical disc, flash memory, hard disk memory,and other memory devices that may us magnetic, optical, and othertechniques to store instructions and other data.

A first aspect of the present subject matter is directed to a method ofestablishing a communication event between an initiating device and aresponding device under the control of a remote communicationscontroller, the method comprising implementing by the initiating devicethe following steps:

in a pre-communication event establishment phase: establishing a secureconnection between the initiating device and the communicationscontroller, exchanging session key negotiation messages between theinitiating device and the communications controller via the secureconnection to obtain, in a memory location accessible to the initiatingdevice, session key data for use by the initiating device in generatingencrypted message payloads that are decryptable by the communicationscontroller, wherein the secure connection terminates once the sessionkey data has been obtained;

in a subsequent communication event establishment phase:

generating a communication event request payload for transmission to thecommunications controller;

encrypting the request payload using the session key data stored in theaccessible memory location; and

in response to a communication event establishment instruction receivedat the initiating device after the session key data has been obtainedand the secure connection has terminated in the pre-establishment phase,transmitting from the initiating device to the communications controllera communication event request comprising the encrypted request payload,thereby causing the communications controller to decrypt the encryptedrequest payload, whereby the communication event between the devices isestablished under the control of the communications controller based onthe decrypted payload.

In embodiments, the request payload may identify the responding device,whereby transmitting the communication event request to thecommunications controller causes the communications controller todecrypt the encrypted request payload and transmit a communication eventinvite to the responding device identified in the decrypted payload.

For example, the request may comprise: a device identifier of theresponding device, and/or a user identifier of a user of the remotedevice, and/or or a network address of the responding device, andthereby identifies the responding device.

The secure connection may be a TLS or HTTPS connection.

The TLS connection may be established using a (reliable) connectionoriented transport protocol, e.g. TCP.

By contrast, the communication event request message may be sent using aconnectionless transport protocol, e.g. UDP. Alternatively, it may besent using an otherwise unsecured connection, e.g. unsecured transportlayer connection such as TCP and/or an unsecured higher layerconnection, such as an HTTP connection.

The session key negotiation messages may be exchanged via the secureconnection at an application layer of a network, above a transport layerof the network.

The session key data may comprise an encrypted version of a session keyreceived from the communications controller in the pre-establishmentphase, the session key having been encrypted by the communicationscontroller using a wrapper key available to communications controller.

As noted above, this allows stateless operation of the communicationscontroller.

Alternatively (or in addition), the session key data may comprise asession key identifier for identifying the session key to thecommunications controller.

The session key data may also comprise:

-   -   a version of the session key not encrypted with the wrapper key,        and/or    -   a client secret and a server secret for generating the        unencrypted version of the session key.

The initiating device may encrypt the request payload using the sessionkey, wherein the request may also comprise:

-   -   the encrypted version of the session key, whereby the request        causes the communications controller to decrypt the session key        using the wrapper key, and decrypt the request payload using the        decrypted session key, and/or    -   the session key identifier.

The initiating device may encrypt the payload using an encryption keyderived from the session key.

For example, the initiating device may generate the encryption key byapplying a key derivation function to the unencrypted version of thesession key, and uses the derived encryption key to encrypt the payload.

Alternatively, the initiating device may generate the encryption key byapplying a key derivation function to the encrypted version of thesession key, and use the derived encryption key to encrypt the payload.In this case session key may not be exchanged via the secure connection.For example, a key exchange mechanism such as the known Diffie-Hellmanalgorithm may be used, to allow the initiating device and thecommunications controller to agree on a symmetric session key withoutever exchanging the agreed upon symmetric session key, in a manner whichmakes it impossible for any snooper to guess the final symmetric key.However, even in this case, in the present context the secure connectionis still used to exchange some unencrypted key derivation input data,even if it is not the session key per se. Accordingly, unencrypted keyderivation input data may be exchanged via the secure connection andused as an input to the key derivation function in generating theencryption key (e.g. as an input to the Diffie-Hellman algorithm).

The session key may be generated by the communications controller, andthe unencrypted version of the session key may be received from thecommunications controller via the secure connection in thepre-establishment phase.

The session key may be generated by the communications controllerindependently of any information provided to the communicationscontroller by the initiating device.

Alternatively, the initiating device may generate a client secret andtransmit it to the communications controller in the pre-establishmentphase, and receives a server secret from the communications controllerin the pre-establishment phase, wherein at least one of the secrets(i.e. one or both of the secrets) is transmitted via the secureconnection; the initiating device may generate an unencrypted version ofthe session key by combining the client secret with the server secret,and use the unencrypted version of session key to encrypt the payload.

The session key data may comprise the session key identifier, and aversion of the session key may be stored in a memory location accessibleto the communications controller in association with the session keyidentifier.

The version of the session key stored in the memory location accessibleto the communications controller may be an encrypted version of thesession key, encrypted with the wrapper key. Alternatively, the versionof the session key stored in the memory location accessible to thecommunications controller may be a version of the session key notencrypted with the wrapper key, which is stored only in volatile memory.

The session key identifier may be received from the communicationscontroller by the initiating device, or the session key identifier isgenerated by the initiating device and transmitted to the communicationscontroller (e.g. GUID).

The request also may also comprise a randomized initialization vectorgenerated by the initiating device, whereby the initiating device canreuse the session key data for a later communication event with adifferent initialization vector.

The initiating device may generate integrity check data by applying ahash function to at least the payload once encrypted, wherein therequest may also comprise the integrity check data, whereby thecommunications controller can use the integrity check data to detect anyalteration to encrypted payload before decrypting it.

The hash function may be applied using an authentication key derivedfrom the session key.

The hash function may be applied to a combination (e.g. concatenation)of the encrypted payload and the initialization vector.

The session key data may also comprises an identifier of the wrapper keyreceived from the communications controller, wherein the requesttransmitted to the communications controller may also comprise theidentifier of the wrapper key, whereby the controller can identify whichwrapper key to decrypt the session key with.

The wrapper key may be stored only in volatile memory accessible to thecommunications controller.

The pre-establishment phase may comprise receiving at the initiatingdevice from the communications controller a timestamp denoting a timemeasured remotely at the communications controller, wherein theinitiating device may store an indication of a difference between theremotely measured time and a time measured locally at the initiatingdevice.

The request may also comprise a timestamp generated by the initiatingdevice accounting for the difference between the locally measured timeand the remotely measured time.

The communications controller may determine a difference between thetimestamp in the request a time of receipt of the request at thecommunications controller, and may be configured to reject the requestif that difference exceeds a first duration.

The communications controller may be a server pool comprising at leasttwo servers having access to shared electronic storage, whereby anyserver of the pool can respond to the request.

The request may also comprise a randomized request identifier generatedby the initiating device.

The request may be received at one of the servers and, in response, theserver may store a copy of at least its request identifier in the sharedstorage, where it remains for a second duration, wherein if anysubsequent request comprising a matching request identifier is receivedat the or another of the servers within the second duration, that servermay ignore the subsequent request.

The communication event establishment instruction may be instigatedmanually by a user of the initiating device. For example the callestablishment instruction may be instigated by the user of theinitiating device: selecting an option on a display of the initiatingdevice to call the responding device and/or a user of the respondingdevice, or providing a voice or gesture input to the initiating devicedenoting the responding device and or the user of the responding device.

A communication client may be installed on the initiating device, andthe pre-establishment phase may be performed as part of the installationof the client or in response to running the installed client on aprocessor of the initiating device for the first time.

Alternatively, the pre-establishment phase may be instigated at a timespecified by a predetermined session key negotiation schedule. Forexample, the session key negotiation schedule may specify that newsession key data should be obtained once every predetermined number ofdays. That is, fresh session key data may be obtained on each occasionspecified by the schedule.

Alternatively, the pre-establishment phase may be performed each time acommunication client is instantiated on a processor of the initiatingdevice. That is, fresh session key data may be obtained each time theclient is instantiated.

According to a second aspect of the present subject matter, a method ofestablishing a session between an initiating device and a remote devicecomprises implementing at the initiating device the following steps:

transmitting a session request from the initiating device to the remotedevice according to a preferred networking protocol;

monitoring by the initiating device an elapsed time for an initialduration from a timing of the transmission;

if no provisional response to the request is received at the initiatingdevice within the initial duration, the first device transmittinganother session request to the other device according to a non-preferredprotocol;

if a provisional response to the request is received within the initialduration, the initiating device continuing to monitor the elapsed timefor an extended duration (e.g. from the transmission of the sessionrequest according to the preferred protocol or from the receipt of theprovisional response),

wherein if no final response to the request is received within theextended duration, the initiating device transmits another sessionrequest to the other device according to a non-preferred protocol;

wherein if a final response is received within the extended duration, asession between the initiating device and the other device isestablished according to the preferred networking protocol.

As such, a session is established between the initiating device and theremote device according to the preferred protocol only if both aprovisional response and a final response are received at the initiatingdevice from the remote device within the initial and extended durationsrespectively. Otherwise, the transmission of the session requestaccording to the non-preferred protocol causes a session to beestablished between the initiating device and the remote deviceaccording to the non-preferred protocol instead.

In embodiments, the session request may comprise a request identifier,and the other session request may comprise a matching requestidentifier.

Multiple session requests may be transmitted from the initiating deviceto the remote device according to the preferred networking protocolwithin the initial duration.

The preferred protocol may be an unreliable transport protocol, and thenon-preferred protocol may be a reliable transport protocol. Forexample, the preferred protocol may be UDP and the non-preferredprotocol may be TCP. E.g. the other session request may be transmittedusing HTTP over TCP.

If at any time during the initial or the extended duration a protocolfallback message is received by the initiating device from the remotedevice, the initiating device may in response transmit a session requestto the remote device according to the non-preferred protocol.

The remote device may be a communications controller, wherein acommunication event is established between the initiating device and aresponding device under the control of the call controller based on theestablished session between the initiating device and the callcontroller.

For example, each of said session requests may identify the respondingdevice, wherein in response to receiving any of said session requeststhe communications controller is able to transmit a communication eventinvite to the responding device identified therein.

The communication event may be a call, a screen sharing session, or ashared whiteboard session.

The initiating device may be configured to apply a compression functionto the session request before transmitting it to reduce its size, andthe session request, once compressed, may be transmitted once the remotedevice in a single packet of the preferred protocol.

The initiating device may be configured, if the session request cannotbe encapsulated in a single packet of the preferred protocol oncecompressed, to transmit the session request to the remote deviceaccording to the non-preferred protocol instead.

The initial duration may be 2 seconds or less from the transmission ofthe session request according to the preferred protocol; and/or theextended duration may be 15 seconds or less from the transmission of thesession request according to the preferred protocol or from the receiptof the provisional response. According to a third aspect of the presentinvention, a method of establishing a session between an initiatingdevice and a remote device comprises implementing at the remote devicethe following steps:

receiving from the initiating device a session request according to apreferred networking protocol;

in direct response to the session request, transmitting to theinitiating device a provisional response to the session requestaccording to the preferred protocol;

processing the session request to generate a final response to thesecond request, wherein the provisional response is transmitted to theinitiating device before said processing has been completed and thefinal response determined; and

transmitting the generated response to the imitating device oncedetermined according to the preferred protocol;

wherein if a matching session request is received from the initiatingdevice according to a non-preferred protocol, in response the remotedevice retransmits to the initiating device a version of the finalresponse according to the non-preferred protocol.

According to a fourth aspect of the present invention, a method ofestablishing a session between an initiating device and a remote devicecomprises implementing at the remote device the following steps:

receiving from the initiating device a session request according to apreferred networking protocol;

processing the request to generate a response (e.g. final response) tothe session request;

determining whether the generate response can be encapsulated in asingle packet of the preferred networking protocol;

is so, transmitting the generated response to the initiating deviceaccording to the preferred protocol in a single packet of the preferredprotocol;

if not, transmitting a protocol fallback message to the initiatingdevice, thereby causing the initiating device to transmit anothersession request to the remote device according to a non-preferredprotocol.

In embodiments of the third aspect, the remote device may store thegenerated response in, and in response to receiving the other sessionrequest from the initiating device according to the non-preferredprotocol, the remote device may retrieve the stored response from theaccessible electronic storage location and transmit it to the initiatingdevice according to the non-preferred protocol.

The remote device may in embodiments of the second or third aspect be acommunications controller and/or a server (e.g. a server of a servercluster of the communications controller).

In embodiments, the preferred networking protocol may be an unreliable(e.g. connectionless) transport protocol (e.g. UDP).

The non-preferred networking protocol may be a reliable (e.g. connectionorientated) transport protocol (e.g. TCP).

A fifth aspect of the present subject matter is directed to a method ofselecting one of a plurality of transport protocols for use by a networkdevice, the method comprising implementing by the network device thefollowing steps:

generating an uncompressed message for transmission to another devicevia a network;

generating a compressed vision of the message, having a reduced messagesize, by applying a compression function to the uncompressed message;

determining the reduced message size of the compressed version;

comparing the reduced message size to a maximum transport packet size ofa preferred one of the transport protocols;

if the reduced message size exceeds the maximum transport packet size ofthe preferred transport protocol, encapsulating the uncompressed or thecompressed version of the message into one or more transport packetsaccording to a non-preferred one of the transport protocols, andtransmitting the one or more transport packets to the other deviceaccording to the non-preferred transport protocol; and

if the size of the compressed message does not exceed the maximumtransport packet size of the preferred transport protocol, encapsulatingthe compressed version of the message into a single transport packetaccording to the preferred transport protocol, and transmitting thetransport packet to the other device according to the preferredtransport protocol.

In embodiments, the preferred networking protocol may be an unreliable(e.g. connectionless) transport protocol (e.g. UDP), whereby the singlepacket is a single datagram of the unreliable transport protocol (e.g.UDP datagram).

The non-preferred networking protocol may be a reliable (e.g. connectionorientated) transport protocol (e.g. TCP), whereby the one or moretransport packets are packet(s) of the reliable transport protocol (e.g.TCP packet(s)).

The compression function may be a dictionary coder compression function.

The network device may be a server device, for example a server deviceof a communications controller.

Alternatively, the network device may be a client device, for example auser device or other computer device, wherein the steps may beimplemented by a communications client executed on a processor of thatdevice.

A sixth aspect of the present subject matter is directed to a method ofestablishing a communication event between an initiating device and aresponding device under the control of a remote communicationscontroller [e.g. server for example of a server cluster with sharedcache], the method comprising implementing by the initiating device thefollowing steps:

in a pre-session establishment phase: receiving at the initiating devicea compression dictionary or a dictionary link that identifies anaddressable memory location, at which a compression dictionary is held;

storing the received compression dictionary or the received dictionarylink in electronic storage of the initiating device;

generating an initial session establishment request message fortransmission to the communications controller;

applying compression to the initial session establishment requestmessage to reduce its size based on the compression dictionary, usingthe stored compression dictionary or by using the stored dictionary linkto access the compression dictionary; and

in response to a communication event establishment instruction receivedat the initiating device after the dictionary or the dictionary link hasbeen received and stored at the initiating device, establishing asession between the initiating device and the communications controllerby the initiating device transmitting the compressed initial sessionestablishment message to the communications controller;

wherein a communication event is established between the initiatingdevice and the responding device based on the established sessionbetween the initiating device and the communications controller.

In embodiments, the communication event establishment instruction may beinstigated by a user of the initiating device, whereby the dictionary ordictionary link is received before the user has instigated thecommunication event establishment instruction.

The call establishment instruction may for example be instigated by theuser of the initiating device: selecting an option on a display of theinitiating device to call the responding device and/or a user of theresponding device, or providing a voice or gesture input to theinitiating device denoting the responding device and or the user of theresponding device. The instigating device may comprise a user interface,via which the instruction is instigated.

The initial session establishment request message may identify theresponding device, whereby transmitting it to the communicationscontroller may cause the communications controller to transmit acommunication event invite to the responding device identified therein.

The initial session establishment request message may comprise a deviceidentifier of the responding device, and/or a user identifier of a userof the remote device, and/or or a network address of the respondingdevice, and thereby identify the responding device.

The session may be established without transmitting any uncompressedmessage from the initiating device to the communications controller.

The dictionary link may be a URI.

The compressed initial session establishment message may be transmittedto the communications controller according to a preferred transportprotocol only if the compressed initial session establishment requestcan be encapsulated in a single packet of the preferred transportprotocol, wherein the initiating device may be configured to otherwisetransmit the initial session establishment request to the communicationscontroller according to a non-preferred transport protocol.

The preferred transport protocol may be an unreliable transport protocol(e.g. UDP) and the non-preferred transport protocol may be a reliabletransport protocol (e.g. TCP).

In embodiments, the dictionary link may be a URI that identifies theaddressable memory location.

That is, the session between the initiating device and thecommunications controller is established without the initiating devicehaving to send any uncompressed message to the communicationscontroller. This is in contrast to, say, HTTPS, which requires at leastthe first message sent from a client to a server to be uncompressed (toaccount for devices that don't support compression).

Any communications event referred to herein may for example be a call,[e.g. call, screen sharing session, shared whiteboard session etc.

According to another aspect of the present subject matter, a networkdevice (e.g. an initiating device or a remote device such as a serverdevice) comprises electronic storage configured to hold executable code,and a processor connected to the electronic storage and configured toexecute the code, wherein the executable code is configured whenexecuted on the processor to implement any of the method steps disclosedherein.

According to yet another aspect of the present subject matter, acomputer program product comprises executable code stored on a computerreadable storage medium and configured, when executed on a processor ofa network device (e.g. an initiating device or a remote device such as aserver device), to implement any of the method steps disclosed herein.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

1. A method of establishing a communication event between an initiatingdevice and a responding device under the control of a remotecommunications controller, the method comprising implementing by theinitiating device the following steps: in a pre-communication eventestablishment phase: establishing a secure connection between theinitiating device and the communications controller, exchanging sessionkey negotiation messages between the initiating device and thecommunications controller via the secure connection to obtain, in anelectronic storage location accessible to the initiating device, sessionkey data for use by the initiating device in generating encryptedmessage payloads that are decryptable by the communications controller,wherein the secure connection terminates once the session key data hasbeen obtained; in a subsequent communication event establishment phase:generating a communication event request payload for transmission to thecommunications controller; encrypting the request payload using thesession key data stored in the accessible electronic storage location;and in response to a communication event establishment instructionreceived at the initiating device after the session key data has beenobtained and the secure connection has terminated in thepre-establishment phase, transmitting from the initiating device to thecommunications controller a communication event request comprising theencrypted request payload, thereby causing the communications controllerto decrypt the encrypted request payload, whereby the communicationevent between the devices is established under the control of thecommunications controller based on the decrypted payload.
 2. A methodaccording to claim 1, wherein the request payload identifies theresponding device, whereby transmitting the communication event requestto the communications controller causes the communications controller todecrypt the encrypted request payload and transmit a communication eventinvite to the responding device identified in the decrypted payload. 3.A method according to claim 2, wherein the request comprises: a deviceidentifier of the responding device, and/or a user identifier of a userof the remote device, and/or or a network address of the respondingdevice, and thereby identifies the responding device.
 4. A methodaccording to claim 1, wherein the session key negotiation messages areexchanged via the secure connection at an application layer of anetwork, above a transport layer of the network.
 5. A method accordingto claim 1, wherein the session key data comprises: an encrypted versionof a session key received from the communications controller in thepre-establishment phase, the session key having been encrypted by thecommunications controller using a wrapper key available tocommunications controller, and/or a session key identifier foridentifying the session key to the communications controller.
 6. Amethod according to claim 5, wherein the session key data alsocomprises: a version of the session key not encrypted with the wrapperkey, and/or a client secret and a server secret for generating theunencrypted version of the session key; and/or key derivation data forgenerating the session key using a key derivation function.
 7. A methodaccording to claim 5, wherein the initiating device encrypts the requestpayload using the session key, wherein the request also comprises: theencrypted version of the session key, whereby the request causes thecommunications controller to decrypt the session key using the wrapperkey, and decrypt the request payload using the decrypted session key,and/or the session key identifier.
 8. A method according to claim 7,wherein the initiating device encrypts the payload using an encryptionkey derived from the session key.
 9. A method according to claims 6 and8, wherein the initiating device generates the encryption key byapplying a key derivation function to the unencrypted version of thesession key, and uses the derived encryption key to encrypt the payload.10. A method according to claim 1, wherein the request also comprises arandomized initialization vector generated by the initiating device,whereby the initiating device can reuse the session key data for a latercommunication event with a different initialization vector.
 11. A methodaccording to claim 1, wherein the initiating device generates integritycheck data by applying a hash function to at least the payload onceencrypted, wherein the request also comprises the integrity check data,whereby the communications controller can use the integrity check datato detect any alteration to encrypted payload before decrypting it. 12.A method according to claims 10 and 11, wherein the hash function is:applied using an authentication key derived from the session key and/orapplied to a combination of the encrypted payload and the initializationvector.
 13. A method according to claim 5, wherein the session key dataalso comprises an identifier of the wrapper key received from thecommunications controller, wherein the request transmitted to thecommunications controller also comprises the identifier of the wrapperkey, whereby the controller can identify which wrapper key to decryptthe session key with.
 14. A method according to claim 1, wherein thepre-establishment phase comprises receiving at the initiating devicefrom the communications controller a timestamp denoting a time measuredremotely at the communications controller, wherein the initiating devicestores an indication of a difference between the remotely measured timeand a time measured locally at the initiating device; and wherein therequest also comprises a timestamp generated by the initiating deviceaccounting for the difference between the locally measured time and theremotely measured time.
 15. A method according to claim 1, wherein therequest also comprises a randomized request identifier generated by theinitiating device.
 16. A method according to claim 1, wherein thecommunication event establishment instruction is instigated manually bya user of the initiating device.
 17. A method according to claim 16,wherein the call establishment instruction is instigated by the user ofthe initiating device: selecting an option on a display of theinitiating device to call the responding device and/or a user of theresponding device, or providing a voice or gesture input to theinitiating device denoting the responding device and or the user of theresponding device.
 18. A method according to claim 1, wherein acommunication client is installed on the initiating device, and thepre-establishment phase is performed as part of the installation of theclient or in response to running the installed client on a processor ofthe initiating device for the first time; or wherein thepre-establishment phase is instigated at a time specified by apredetermined session key negotiation schedule, or wherein thepre-establishment phase is performed each time a communication client isinstantiated on a processor of the initiating device.
 19. An initiatingdevice for establishing a communication event between the initiatingdevice and a responding device under the control of a remotecommunications controller, the initiating device comprising: a networkinterface; memory holding executable code; and a processor connected tothe memory and configured to execute the code, wherein the code isconfigured when executed on the processor to implement the followingsteps: in a pre-communication event establishment phase: establishing asecure connection between the initiating device and the communicationscontroller, exchanging session key negotiation messages between theinitiating device and the communications controller via the secureconnection to obtain, in the electronic storage, session key data foruse by the initiating device in generating encrypted message payloadsthat are decryptable by the communications controller, wherein thesecure connection terminates once the session key data has beenobtained; in a subsequent communication event establishment phase:generating a communication event request payload for transmission to thecommunications controller; encrypting the request payload using thestored session key data; and in response to a communication eventestablishment instruction received at the initiating device after thesession key data has been obtained and the secure connection hasterminated in the pre-establishment phase, transmitting from theinitiating device via the network interface to the communicationscontroller a communication event request comprising the encryptedrequest payload, thereby causing the communications controller todecrypt the encrypted request payload, whereby the communication eventbetween the devices is established under the control of thecommunications controller based on the decrypted payload.
 20. A computerprogram product comprising executable code stored on a computer readablestorage medium and configured when executed on a processor of aninitiating device to establish a communication event between aninitiating device and a responding device under the control of a remotecommunications controller by implementing the following steps: in apre-communication event establishment phase: establishing a secureconnection between the initiating device and the communicationscontroller, exchanging session key negotiation messages between theinitiating device and the communications controller via the secureconnection to obtain, in an electronic storage location accessible tothe initiating device, session key data for use by the initiating devicein generating encrypted message payloads that are decryptable by thecommunications controller, wherein the secure connection terminates oncethe session key data has been obtained; in a subsequent communicationevent establishment phase: generating a communication event requestpayload for transmission to the communications controller; encryptingthe request payload using the session key data stored in the accessibleelectronic storage location; and in response to a communication eventestablishment instruction received at the initiating device after thesession key data has been obtained and the secure connection hasterminated in the pre-establishment phase, transmitting from theinitiating device to the communications controller a communication eventrequest comprising the encrypted request payload, thereby causing thecommunications controller to decrypt the encrypted request payload,whereby the communication event between the devices is established underthe control of the communications controller based on the decryptedpayload.